The invention relates generally to automatic data collection (xe2x80x9cADCxe2x80x9d) devices and more particularly to transmitting data received from ADC devices.
Automatic Data Collection (xe2x80x9cADCxe2x80x9d) device platforms, such as ADC device platforms equipped with bar code readers, have received increasing commercial attention in the past few years. ADC device platforms, such as hand-held data collection terminals, or hand-held personal computers, have been widely implemented in the retail marketplace and have garnered increasing utilization in a diverse range of application areas. The ever-decreasing cost and size of ADC device platforms has facilitated their entry into a wide variety of commercial, institutional, and governmental settings.
An ADC device platform having a bar code reader adeptly accesses and retrieves data stored in the form of a bar code label. Data representing virtually any product or service found in the stream of commerce may be encoded in a bar code label for later access by an ADC device platform having a bar code reader. Bar code readers include laser scanners as well as other means of collecting product information, such as a bar code wand, a still camera or an area imager. In addition to bar code labels, other ADC data formats include Radio Frequency (xe2x80x9cRFxe2x80x9d) tags, resonators, SmartCards, magnetic strips, Optical Character Recognition (xe2x80x9cOCRxe2x80x9d), speech input, two-dimensional (xe2x80x9c2Dxe2x80x9d) symbols, dipole devices (such as those recited in U.S. Pat. No. 5,581,257), and any symbol having encoded data therein.
In a conventional ADC device platform environment, the recipient of ADC data either physically manipulates the ADC device platform itself to retrieve the ADC data or receives the ADC data through a local, and probably proprietary, network. Thus, a typical ADC device operator is limited both in terms of the distance from which the operator may be located away from the actual device and by the complexity and versatility of the elements that comprise the ADC device network which the operator utilizes. The operator suffers from still further limitations due to the fact that many conventional ADC device platforms are not readily configurable for new ADC devices, or even for ADC devices other than those attached to the ADC device platform when it is initially sold. Yet another limitation in a conventional ADC device platform arises when an operator wishes to add a new ADC device to one of the few ADC device platforms that will accept new ADC devices. This limitation stems from the fact that many ADC devices require proprietary communications protocols, and even when the communications protocols are non-proprietary, the communications protocols are typically non-standard. Thus, the operator cannot simply attach a new ADC device to an existing ADC device platform and expect that the new combination will function properly. Finally, the above limitations, both separately and together, hinder an ADC operator""s ability to customize the ADC device platform to operate in the most productive manner possible.
Input data received by an ADC device platform must be routed to the intended destination. Conventional ADC device platforms typically have a simple connection that routes one type of data from a single ADC device to a single destination, typically an application program. However, ADC device consumers presently demand more sophisticated ADC device platforms that receive data from multiple ADC devices and route the data, of multiple types, to multiple destinations. While data routing decisions may be permanently fixed in an ADC device platform""s basic design, such an approach provides only minimal flexibility and does not accommodate the addition of new ADC devices and new data recipients. Moreover, such an approach also prevents existing data recipients from reconfiguring their data routing instructions. ADC device consumers would like to register their specific data requests with an ADC device platform, including the specification of logical relationships and various contingencies with regard to the routing of ADC data. Finally, ADC data consumers expect that their data processing applications will operate upon data received from ADC devices regardless of whether the application recognizes specific ADC data types.
The invention provides a method and system for dynamically wedging data received from one or more automatic data collection (xe2x80x9cADCxe2x80x9d) devices on an ADC device platform into a destination application based upon wedging criteria. Applicable criteria for routing data may be user-composed and may pertain to firmware or software characteristics.
An ADC computing system having a dynamic wedge capability receives data from one or more ADC devices and automatically routes the data to applications based upon previously stored dynamic wedge directives, according to an aspect of the invention. Aspects of the ADC computing system having a dynamic wedge capability provide an efficient mechanism for channeling ADC data from one or more ADC devices to one or more client applications with a high degree of flexibility and user control.
A dynamic wedge mechanism may comprise an ADC data server in the ADC computing system, ADC device handlers, ADC protocol handlers, and a dynamic wedging grid that retains wedging directives, according to an aspect of the invention. The ADC data server receives wedging directives from local and remote client applications and stores the wedging directives in the dynamic wedging grid. When data arrives from an ADC device, a device-specific ADC data handler and a device-specific ADC protocol handler transform the data into a format operable by the ADC data server. The ADC data server analyzes the data to determine its characteristics. The ADC data server compares the identified characteristics against the wedging directives stored in the dynamic wedging grid. The ADC data server determines for which client applications a match has been found. For those clients for which a match has been found, the ADC data server then processes the appropriate wedging directive in order to dispose properly of the received ADC data. Aspects of the dynamic wedge may route ADC data to an application, both local and remote, to a virtual wedge, to a data file, or to any location that a client application may direct the sending of data.
Aspects of the invention operate in multiple client environments in which a client may receive data from multiple ADC devices, and multiple clients may receive data from the same ADC device. Aspects of the invention are applicable for dynamically wedging data received from ADC devices such as bar code readers, resonator readers, voice recognition devices, RF tag readers, detachable keyboards, two-dimensional symbol readers, ASCII data devices, AIMI-ECI data devices, dipole device readers, and optical character (xe2x80x9cOCRxe2x80x9d) devices. In addition, aspects of the invention accommodate the later addition of other ADC devices. Thus, the invention enables a user to reconfigure the ADC device platform for new data collection environments.